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EXAMINER'S ANSWER 



This is in response to the appeal brief filed 12/19/2007 appealing from the Office action 
mailed 08/03/2007. 
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(1) Real Party in Interest 

A statement identifying by name the real party of interest is contained in the brief. 

(2) Related Appeals and Interferences 

The examiner is not aware of any related appeals, interferences, or judicial 
proceedings which will directly affect or be directly affected by or have a bearing on the 
Board's decision in the pending appeal. 

(3) Status of Claims 

The statement of the status of claims contained in the brief is correct. 

(4) Status of Amendments After Final 

The appellant's statement of the status of amendments after final rejection 
contained in the brief is correct. 

(5) Summary of Claimed Subject Matter 

The summary of claimed subject matter contained in the brief is correct. 

(6) Grounds of Rejection to be Reviewed on Appeal 

The appellant's statement of the grounds of rejection to be reviewed on appeal is 
correct. 

(7) Claims Appendix 

The copy of the appealed claims contained in the Appendix to the brief is correct. 

(8) Evidence Relied Upon 

2003/0236912 KLEMETS 12/2003 
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(9) Grounds of Rejection 

The following ground(s) of rejection are applicable to the appealed claims: 
Claim Rejections - 35 USC § 102 

1 . The following is a quotation of the appropriate paragraphs of 35 U.S.C. 1 02 that 
form the basis for the rejections under this section made in this Office action: 

A person shall be entitled to a patent unless - 

(e) the invention was described in (1 ) an application for patent, published under section 1 22(b), by 
another filed in the United States before the invention by the applicant for patent or (2) a patent 
granted on an application for patent by another filed in the United States before the invention by the 
applicant for patent, except that an international application filed under the treaty defined in section 
351(a) shall have the effects for purposes of this subsection of an application filed in the United States 
only if the international application designated the United States and was published under Article 21(2) 
of such treaty in the English language. 

2. Claims 1-4, 6-14, and 16-17 are rejected under 35 U.S.C. 102(e) as being 
anticipated by US Patent Application Publication number US 2003/0236912 A1 to 
Klemets et al., hereafter referred to as "Klemets." 

With regards to claim 1 , Klemets discloses a method for streaming a media file 
over a distributed information system to a client computer running a browser application, 
the method comprising the steps of: receiving a request for a particular media file from a 
client computer (Klemets: Paragraph [0016]); providing a metafile, whereby said 
metafile contains information about the identification (Klemets: Paragraph [0038]. The 
"Title" field is information about the identification.), location (Klemets: Paragraphs [0012] 
and [0041]. The metadata includes a stream attribute identifying a media stream, where 
a media stream identifier has a one to one relationship with a URL, which means that 
the stream attribute constitutes location information.), and format (Klemets: Paragraph 
[0035]. The metadata can be the encoded bit rate and the language, both of which 
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constitute format.) of the media file, returning said metafile back to said client computer 
(Klemets: Paragraph [0039]), characterized in that the step of receiving a request for a 
particular media file from a client computer further comprises the steps of: intercepting a 
download request for the actual media file (Klemets: Figure 1 . The media server 
intercepts the request from the client, and serves the media file from the file system to 
the client.) and reinterpreting said download request in a request for receiving a 
corresponding metafile (Klemets: Paragraph [0033]. As a result of the server receiving 
a request for a media file, the server requests metadata items from the file system 
and/or encoder. As the server is requesting items in addition to the one that the client 
requested, the request has been "reinterpreted" into a request for the media file and the 
metadata.). 

With regards to claim 2, Klemets discloses that the step of reinterpreting said 
download request includes the step of deriving information about said corresponding 
metafile from a portion of the URL (Klemets: Paragraph [0031]. The URL determines 
the media file being requested, meaning that it is utilized, at least in part, to obtain the 
metadata.). 

With regards to claim 3, Klemets discloses that the portion of the URL is the file 
extension of the requested media file (Klemets: Paragraph [0056]. The system of 
Klemets assigns attributes based in part if the format is ASF, which is the file extension 
as per paragraph [0031]). 

With regards to claim 4, Klemets discloses that the step of providing a metafile 
comprises the steps of: dynamically generating a metafile (Klemets: Paragraph [0038]), 
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and statically querying a metafile (Klemets: Paragraph [0038]. As the metadata items 
may be obtained from a separate file, the file is "queried" for the information.). 

With regards to claim 6, Klemets discloses that the step pf providing a metafile 
further includes the step of retrieving information about the configuration of at least one 
item chosen from the group comprising: version of the streaming product, type of the 
streaming product, location of the media file, load of the servers, load of the network, 
location of the client, quality of service (Klemets: Paragraphs [0049], [0074], [0075]. 
The items in the list are broad, as information about the version of the streaming 
product could constitute the file name, which is included in Klemets. The type of the 
streaming product can constitute any number of elements, some examples being found 
in the cited paragraphs. Also, to meet the claim language, any configuration information 
meets the language, as the group comprises version, type, location, load of the 
servers, load of the networks, location of the client, and quality of service. The open- 
ended language does not exclude the configuration information from being an element 
not on the list.). 

With regards to claim 7, Klemets discloses that the step of providing a metafile 
further includes reading information about the client's preferred streaming format and 
forming a metafile in accordance with the client's preference (Klemets: Paragraph 
[0044]. The client is able to select different parameters involved with the streaming 
media file, including whether the file will be played as just audio, or as audio and video. 
As the metafile is able to be generated based on the client's request, these factors 
would be at least read and used somehow to generate the metafile.). 
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With regards to claims 8-14 and 16-17, the claimed subject matter is substantially 
similar to the subject matter found in claims 1-4 and 6-7, and is rejected for substantially 
similar reasons. 

With regard to claim 18, the instant claim is substantially similar to subject matter 
presented in claims 1-4, 6-13, and 15-17, with the exception that a MIME-type is 
provided at the metadata server and returned with the metafile to the client computer. 
However, Klemets discloses that a MIME type is included in the header, which is 
returned to the client (Klements: Paragraph [0049]). 

Claim Rejections - 35 USC § 103 

3. The following is a quotation of 35 U.S.C. 1 03(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set 
forth in section 102 of this title, if the differences between the subject matter sought to be patented and 
the prior art are such that the subject matter as a whole would have been obvious at the time the 
invention was made to a person having ordinary skill in the art to which said subject matter pertains. 
Patentability shall not be negatived by the manner in which the invention was made. 

4. Claims 5 and 15 are rejected under 35 U.S.C. 103(a) as being unpatentable over 
Klemets over knowledge possessed by a person of ordinary skill in the art. 

With regards to claim 5, Klemets discloses the invention as substantially claimed 
(see above for claim 1 rejected under Klemets) except checking predefined filter criteria 
determining of whether or not a metafile is to be returned instead of the requested 
media file. 

A person of ordinary skill in the art would have known how to perform this 
functionality. If the metafile is returned, the media file is to be streamed. If the media 
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file is returned, then the media file is being downloaded rather than being streamed. 
The predefined filter can simply be the determination of what kind of request is being 
presented from the client. 

It would have been obvious at the time of the invention to give the client a choice 
to download the media file or stream the media file, as represented by providing the 
metafile, in the system of Klemets. 

The suggestion/motivation for doing so would have been that different system 
configurations and network configurations has a preference for downloading or 
streaming. In cases where memory is limited, streaming may be preferred. In cases 
where bandwidth is limited, downloading may be preferred, as the connection speed 
may not be able to support the streamed media, while a download would allow the user 
to access the media at an acceptable quality at a later time. Even if bandwidth is not 
limited, downloading may still be preferable as the client would have its own copy of the 
media file, allowing the client to access the file as often as desired without requiring a 
connection. Allowing a choice to be made based on the request, and providing a filter 
that determines whether the request should be responded to with metadata to allow 
streaming or the media file itself allows the client to optimize access to the file based on 
network conditions, the client's configuration, and the user's preferences. 

With regards to claim 15, the claim is substantially similar to claim 5, and is 
rejected for substantially similar reasons. 



Application/Control Number: 10/624,353 Page 8 

Art Unit: 2100 

(10) Response to Argument 
Issue 1: Appellant argues on pages 14-17 of the Appeal Brief that Klemets does not 
disclose certain features of claim 1 . More specifically, Appellant focuses on "receiving a 
request for a particular media file from a client computer". 

First, it is noted that the phrase "receiving a request for a particular media file 
from a client computer" does not necessarily mean that the request is to download the 
particular media file. This point is similar to an argument presented in the Advisory 
Action mailed on 10/15/2007 on page 3, which Appellant did not ever address, even in 
the Appeal Brief. Even the phrase "intercepting a download request for the actual 
media file" does not necessarily mean that the request is a request to download the 
actual media file. In both cases, the phrases "for a particular media file" and "for the 
actual media file" could mean either that the request is to acquire, or download, the 
media file (which is the interpretation that Appellant is apparently relying upon), or that 
the request is with regard or respect to a particular media file (which is clearly within the 
scope of the instant claims, and is the interpretation relied upon by the Examiner). 

According to MPEP 21 1 1 , claims must be given their broadest reasonable 
interpretation consistent with the specification. The instant application makes 
references to downloading the actual file, as Appellant argues, as well as requests to 
stream a media file (See, for example, the instant specification, page 4, paragraph 1). 
Thus, the broadest reasonable interpretation consistent with the specification of the 
phrase "for a particular media file" is "with regard or respect to a particular media file." 
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As the metadata file is a file that includes data about the media file, a request to obtain 
the metadata file is "with regard or respect to a particular file." 

Accordingly, the interpretation that must be given to the instant claims is broader 
than the interpretation that Appellant argues with respect to claim 1 . As such, the 
DESCRIBE method, as in Klemets, may include the streaming media header 
(metadata), and the DESCRIBE method is made with regard or respect to the particular 
media file that the user wishes to stream, and is thus for the particular media file. 

Appellant further argues that intercepting and reinterpreting, as in claim 1, is not 
disclosed or suggested by Klemets. However, it is noted that the instant claim does not 
state what component intercepts the request, or that the component performing the 
interception step is not the intended destination. Further, the instant claim does not 
require that the request was interpreted initially, or that the reinterpreting is converting 
the request into a different kind of message. Any message that is transmitted from a 
client to a server, and is processed by the server can be said to be reinterpreted, as the 
client makes the initial interpretation when creating the message, then the server 
reinterprets the message in order to process the message. Without any functionality 
claimed with regard to these steps, or any explicit definition of these terms that has a 
limiting effect on the instant claims, these terms, in the context of the instant claims, 
must be given their broadest reasonable interpretation from the perspective of a person 
of ordinary skill in the art in light of the specification. 
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Issue 2: Appellant argues on pages 18-20 that Klemets does not disclose the features 
of claims 1 8 for the reasons stated with regard to claims 1 and 1 1 (see Issue 1 ), and 
additionally the sequential interactions with two different servers, the first being a 
metadata server and the second being a streaming server. 

However, as Examiner previously argues, and recognized by Appellant (see 
page 19 of Appeal Brief, paragraph 3), the servers both may be implemented in 
software alone, with an exemplification that the servers have a mutual connection to a 
network (which clearly occurs if both server programs are utilized on the same computer 
device). According to the specification, a single computer program product an comprise 
all the features enabling the implementation of the methods described, which can carry 
out the methods when loaded in a single computer system (Specification, page 18, lines 
1 8-21 ). It is noted that the instant specification never explicitly states that the two 
servers must be implemented on separate computing devices, only that they may be 
implemented on "a computer system, such as a personal computer, a laptop computer 
or a server computer" (Specification: Page 10, lines 14-15) in the case of the metadata 
server, or on "a server computer" (Specification: Page 11, lines 1-2) in the case of the 
deliver server (which is equivalent to the streaming server). Both servers are 
implemented as programs (Specification: Page 10, lines 14-15 and Page 11, lines 1-2) 
running on systems that do not necessarily appear to be dedicated to the functionality 
included within the server programs. 

There is no explicit statement that the servers must be implemented on separate 
computing devices, nor is there a claim limitation that requires the servers to be 
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implemented on separate computing devices, or be distinct in any way other than being 
separate software portions to perform the different functions of the respective servers, 
nor that the separate servers utilize a network to communicate directly between the two 
servers. On the contrary, all communications appear to be between one of the servers 
and the client, not between the two servers, and definitely not between the two servers 
over a network within the disclosure of claim 1 8. 

As such, claim 18 clearly covers embodiments where the streaming server and 
metadata server are on different computing devices as well as where the streaming 
server and metadata server are implemented as parts of the same computer program 
on a single computing device. 

Issue 3: Appellant argues on pages 21-23 that a person of ordinary skill in the art would 
not have been able to perform the step of "checking predefined filter criteria determining 
of whether or not a metafile is to be returned instead of the requested media file." First, 
it is noted that Appellant has not referenced the Advisory Action sent on 10/15/2007 at 
all in the Appeal Brief. Thus, the contents of the Advisory Action that pertain to this 
argument is presented below. 

"On pages 1 2-1 3, Applicant argues that a person of ordinary skill in the art would 
have known how to perform the step of "checking predefined criteria determining 
whether or not a metafile is to be returned instead of the requested media file." In 
response, the interpretation of the claim, and the logic for this assertion is presented 
below. However, if Applicant, in a subsequent response, continues to question this 
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feature, with specific arguments against the interpretation and the logic presented in 
points A to E, below, Examiner will present a reference to show this functionality. 

A. A metafile is returned in situations where the media file is to be streamed, 
with the metafile including the necessary information for the client to properly stream the 
file. 

B. "Checking predefined filter criteria," as claimed, only requires that the server 
applies some sort of rules, policies, or other instructions to determine to perform the 
claimed functionality. 

C. Requests to perform specific functionality is very well known in the art. For 
example, a request to connect, a request to stream, a request to download, a request to 
disconnect, etc. 

D. Having a server apply some sort of rules, policies, or other instructions to 
determine what kind of request was presented is well known in the art. For example, a 
server will apply some rules, policies, or instructions to determine if it received a 
"request to connect," "a request to stream," "a request to download," "a request to 
disconnect," etc. 

E. The instant claims do not specific disclose what kind of request is received. 
The claims do not even require the basis for which the determination is made (e.g. the 
file is not available for streaming, the client has a certain amount of bandwidth making 
downloading a better option, or the specific kind of request is for either streaming or 
downloading, etc.). 
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Therefore, the limitation added by claims 5 and 15 are met if a server is capable 
of checking incoming requests to determine if the request was a request for download 
or a request to stream. 

Applicant should amend the instant claim to demonstrate what kind of criteria are 
utilized in order to make the determination if the criteria is not intended to include 
determining what kind of request was made by the client. Otherwise, Applicant has 
specific arguments that the above points are somehow erroneous, Examiner will provide 
a reference to support the conclusions." 

Examiner presented specific arguments of how this functionality would have 
been known to a person of ordinary skill in the art, and presented distinct ways for 
Appellant to argue that this functionality would not have been known to a person of 
ordinary skill in the art (i.e. to argue the logic presented in points A to E). 

Further, the instant specification states "Usually, a HTTP protocol handler would 
answer an HTTP request by either returning the content of the resource requested 
(default HTTP behavior), or by executing the resource and forwarding it's reply (JAVA 
Servlets, CGI Scripts)." (Specification: Page 12, lines 1-3). Thus, it is clear that an 
HTTP protocol handler usually has the capability to determine what the request is and 
respond appropriately. This is equivalent to checking some predefined filter criteria to 
determine what kind of request was provided. Further, Appellant recognizes that HTTP 
has been used to stream files (Specification: Page 3, lines 13-15), and there is no 
question that HTTP can be used to download files. Clearly, servers that respond to 
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requests must be able to identify what kind of request is being made in order to properly 
respond to the request. 

Thus, having a server that is capable of checking incoming requests to determine 
if the request was a request for downloading the media file or a request to stream the 
media file is within the grasp of a person of ordinary skill in the art, and has been 
implemented in many servers, even those recognized in Appellant's specification as 
having existed. 

(11) Related Proceeding(s) Appendix 

No decision rendered by a court or the Board is identified by the examiner in the 
Related Appeals and Interferences section of this examiner's answer. 

For the above reasons, it is believed that the rejections should be sustained. 
Respectfully submitted, 
/S. C.I 

Examiner, Art Unit 2144 

/William C. Vaughn, Jr./ 

Supervisory Patent Examiner, Art Unit 2144 

Conferees: 

/William C. Vaughn, Jr./ 
Supervisory Patent Examiner, Art Unit 2144 
/John Follansbee/ 



Application/Control Number: 10/624,353 Page 15 

Art Unit: 2100 

Supervisory Patent Examiner, Art Unit 2151 



